home *** CD-ROM | disk | FTP | other *** search
/ Hacker's Secrets 4 / Hacker's Secrets 4.iso / misc / telnet.txt < prev    next >
Text File  |  1996-06-23  |  26KB  |  631 lines
  1.  
  2. **************************************************************************
  3.    TIP: Telnetd security vulnerability
  4. System:
  5. Source: Sam Hartman, MIT Kerberos Development team
  6.   Date: 15 Oct 1995
  7. **************************************************************************
  8.  
  9.                                Contents
  10. * Preface and History
  11. * Quick Fix
  12. * Environment Variables that Matter
  13. * Affected Telnetds
  14. * Telnetds that Work
  15. * Availability of Patches
  16. * Testing for Exposure
  17. * Verifying a Patch
  18. * Sample Patch
  19. * Acknowledgments
  20.  
  21.  
  22.  
  23.                          Preface and History
  24.  
  25.         On Sunday, October 15, I discovered a bug in some versions of
  26. telnetd on some platforms that allows a user making a connection to
  27. cause login to load an alternate C library from an arbitrary location
  28. in the filesystem of the machine running telnetd.  In the case of
  29. machines mounting distributed filespaces such as AFS or NFS,
  30. containing publicly writable anonymous FTP directories, or on which
  31. the user already has a non-root account, it is possible to gain root
  32. access.
  33.  
  34.         The problem is that telnetd will allow the client to pass
  35. LD_LIBRARY_PATH, LD_PRELOAD, and other run-time linker options into the
  36. process environment of the process that runs login.  If the runtime
  37. linker honors these options for login, the attacker can cause a custom
  38. libc to be loaded. Such a libc could, for example, start a shell
  39. whenever some function like crypt() is called.  If login calls this
  40. function before the setuid call, then the attacker will gain root
  41. access.
  42.  
  43.         Note that the user must be able to convince telnetd to run
  44. login in order for this attack to be successful.  In particular, if an
  45. authentication system such as Kerberos is employed, and the telnetd
  46. requires authentication, then only users with valid accounts will be
  47. able to use this attack.
  48.  
  49.  
  50.  
  51.                               Quick Fix
  52.  
  53.         Normally, programs that run with the set-user-ID or
  54. set-group-ID bit set do not use environment variables to pass
  55. information about where to find libraries.  This is designed to
  56. prevent attacks where an intruder sets LD_LIBRARY_PATH and runs `su'
  57. or `login' from the command line.  Since these are set-user-ID
  58. programs, they run as root; if they trust LD_LIBRARY_PATH, then they
  59. can load a user-supplied libc and be as insecure as telnetd.  The test
  60. used by most runtime linkers to determine if LD_LIBRARY_PATH can be
  61. trusted checks to see if the effective user ID is equal to the real
  62. user ID.  Since telnet is started as a root-owned process by inetd,
  63. its real user ID is root.  So, even if login is set-user-ID, the test
  64. succeeds and LD_LIBRARY_PATH is trusted, creating the security
  65. problem.
  66.  
  67.         On many systems, if login is made set-group-ID, the test will
  68. fail because login's effective group will be different than the real
  69. group.  This should only be used on a temporary basis.  Unfortunately,
  70. this doesn't always work: in particular, it doesn't work for SGI Irix.
  71. (SGI has already released a patch, but other systems may exist where
  72. this also fails.)  If you try this fix, you should go through the
  73. "Testing for Exposure" section.
  74.  
  75.         To make login set-group-ID follow these steps:
  76.  
  77. 1) Create a new group (you might want to call it `__login',
  78.    `__telnet', `tnbug' or something of the sort). In the rest of this
  79.    document, I will assume that you have called the group `__login'.
  80.    Make sure the group doesn't already exist, and make sure that no
  81.    other programs are moved into this group.  For information on how
  82.    to create a group, consult your vendor's manuals and the man page
  83.    for /etc/group.
  84.  
  85. 2) Find your login program; it is often /usr/bin/login or /bin/login.
  86.    I will assume here that it is /bin/login.  Under AIX and some other
  87.    operating systems, login may be a symlink to another program;change
  88.    the group of the actual program, not of the symlink.
  89.  
  90. 3) Look at the current permissions on login:
  91.    bash$ ls -l /bin/login
  92.    lrwxrwxrwx   1 root     system        13 Mar  8 1994  /bin/login ->
  93.                                                                 /usr/sbin/tsm
  94.    bash$ ls -lL /bin/login
  95.    -r-sr-xr-x   3 root     security   59217 Aug 23 1994  /bin/login
  96.    bash$
  97.  
  98.         Note that because I am running on an AIX system, I gave the -L
  99. option to the second ls in order to trace through the symlink and find
  100. the real login.  You should remember what group login is in so you can
  101. change things back after you get a vendor patch.
  102.  
  103. 4) Change the group of login and set the set GID bit:
  104.    bash$ su
  105.    root's Password:
  106.    bash# chgrp __login /bin/login
  107.    bash# chmod g+s /bin/login
  108.    bash# ls -lL /bin/login
  109.    -r-sr-sr-x   3 root     __login      59217 Aug 23 1994  /bin/login
  110.    bash#
  111.  
  112.  
  113.                   Environment Variables that Matter
  114.  
  115.         This is not an exhaustive list of environment variables
  116. telnetd should filter, but it does contain several of the key
  117. variables on systems used at MIT and by people with whom I have
  118. consulted:
  119.  
  120. LD_LIBRARY_PATH: At least Solaris, SunOS, NetBSD, Linux and Digital
  121.    Unix use this as the path to look for shared libraries in.
  122.  
  123. LD_PRELOAD: Solaris and possibly others load these object modules into
  124.    the address space of the process before loading other shared
  125.    libraries.
  126.  
  127. LIBPATH: AIX uses this to locate its shared libraries.
  128.  
  129. ELF_LD_LIBRARY_PATH: May be used by the Linux Elf loader; similar to
  130.    LD_LIBRARY_PATH in function.  According to the author of Linux
  131.    ld.so (hjl@nynexst.com), this was only used by ld.so version 2.6.
  132.    This version was only used for beta Elf development, and is
  133.    apparently not used by any production Linux distributions.
  134.  
  135. LD_AOUT_LIBRARY_PATH: Another Linuxism from ld.so-1.7.3.  Same as
  136.    LD_LIBRARY_PATH but only for a.out libraries.
  137.  
  138. _RLD_ROOT: Digital Unix uses this to specify a prefix prepended to
  139.    library paths stored inside executables.
  140.  
  141. _RLD_LIST: A list of objects dynamically loaded into an executable by
  142.    Digital Unix.
  143.  
  144. _RLD_*: Used by Digital Unix and SGI.  There are several apparently
  145.    undocumented variables in /sbin/loader on Digital Unix and in the
  146.    SGI runtime linker.
  147.  
  148. LD_*: Several other variables have special meaning to certain
  149.    operating systems.  Stripping all these variables would probably be
  150.    a good idea.
  151.  
  152. IFS: It is possible that setting IFS could cause damage in
  153.    environments where the user logs into an account that runs a shell
  154.    script instead of granting full access.
  155.  
  156.  
  157.                           Affected Telnetds
  158.  
  159.         All telnetds derived from the Telnet package distributed by
  160. David Borman allow the environment options to be passed.  Borman has
  161. released a patch for the problem as of October 19.  The patch released
  162. on October 19, while secure, has a bug that prevents any telnet
  163. environment options from being handled.  Another patch was released on
  164. October 23 that appears to work; see below for details.  Besides his
  165. original release, here are a list of operating systems and security
  166. packages I'm aware of that include derivatives of this work:
  167.  
  168. * NetBSD and FreeBSD are distributed with a vulnerable
  169.   telnetd.  (See below for patch info.)
  170.  
  171. * The version of telnetd maintained in the Kerberos version 5
  172.   distribution by MIT. (patch available)
  173.  
  174. * The Cygnus Network Security V4 95Q1 Free Network Release includes a
  175.   vulnerable telnetd. (Previous releases did not contain telnetd.) A
  176.   patch has been released.
  177.  
  178. * OpenVision's OV*Secure contains a telnetd that is vulnerable; a
  179.   patch is available.
  180.  
  181.  
  182.                Other Vulnerable Telnetd Implementations
  183.  
  184.         This problem is not unique to code derived from the Borman
  185. telnet distribution.  Other vulnerable implementations are known to
  186. include:
  187.  
  188. * SGI Irix 5.3 (patch available)
  189.  
  190. * Digital Unix. The telnetd distributed with stock Digital Unix
  191.   appears to be vulnerable.  DEC confirms they are investigating.
  192.  
  193. * Linux. The telnetd distributed with Slackware Linux appears to be
  194.   vulnerable, although I have not verified this.  The maintainers of
  195.   Debian GNU/Linux confirm their telnetd is vulnerable and released a
  196.   patch; see below.  A patch is also available for Redhat Linux.
  197.  
  198.  
  199.                           Telnetds that Work
  200.  
  201.         Below is a list of operating systems which come with telnetds
  202. that we know are not vulnerable.
  203.  
  204. * SunOS 4.1.4. The Sunos 4.1.4 telnetd does not support passing of
  205.   environment variables, so it is not vulnerable.
  206.  
  207. * IBM AIX 4.1. This telnetd does not support environment options.
  208.  
  209. * BSDI's BSD/OS. While the telnetd will pass any environment option,
  210.   there doesn't appear to be an option to override the shared library
  211.   path, so BSD/OS is probably not vulnerable.  On October 19, Dave
  212.   Borman <dab@cray.com> confirmed that BSDI is not vulnerable to the
  213.   attack, although the telnetd will accept any environment variable.
  214.  
  215. * Telnetd on other systems that do not support shared libraries.
  216.   This includes DEC Ultrix, and Cray Unicos.
  217.  
  218. * According to LaMont Jones <lamont@cranston.fc.hp.com>, "HP-UX is not
  219.   vulnerable to this attack, due to our shared library
  220.   implementation."
  221.  
  222.         Note that both AIX and SunOS can be vulnerable if the stock
  223. telnetd is replaced.  Also, note that the stock Solaris telnetd has
  224. not been tested.
  225.  
  226.  
  227.                        Availability of Patches
  228.  
  229.         This is a list of patches I'm aware of at this time.  As you
  230. develop a patch for your product/platform, please let me know;
  231. considering free operating systems affected by this problem, widely
  232. announcing the bug once patches are available is very important.  Note
  233. that these patches are provided as-is, without any guarantee of
  234. correctness or security on the part of MIT, myself, or the patch
  235. creator.  They are provided in a spirit of cooperation, not as a
  236. guaranteed fix.  I cannot certify the degree of testing applied to
  237. these patches.  Note that CERT and CIAC plan to announce bulletins
  238. about this problem on October 31, 1995.  Where this memo conflicts
  239. with the information provided in the CERT advisory, assume
  240. CERT's information is more accurate: they have better vendor contacts,
  241. and have been actively confirming patch availability for the last few
  242. days.
  243.  
  244.         I am including this section in order to provide users with
  245. patch locations, where possible, in the same place where they first
  246. encounter details about this problem.I am maintaining it with
  247. information I receive, but not all vendors have replied to my earlier
  248. memo, so if your favorite vendor isn't listed here, check the CERT
  249. advisory before contacting them.
  250.  
  251. * On October 19, David Borman <dab@cray.com> released a new version of
  252.   his telnet package, containing a fix to the problem.  This original
  253.   patch disabled passing environment options entirely, but was revised
  254.   on October 23.  The revised patch, and instructions for obtaining it
  255.   are contained at the bottom of this message.  Note that this patch
  256.   does not deal with the ELF_LD_LIBRARY_PATH, although for most Linux
  257.   users, this is not a problem.  The version of telnet on
  258.   net-dist.mit.edu contains this patch.
  259.  
  260. * Greg Hudson <ghudson@mit.edu> checked a patch into the
  261.   NetBSD-current source tree.  This patch will be incorporated by any
  262.   NetBSD-current users who update to the current telnetd.  It will be in
  263.   the NetBSD 1.1 release.  NetBSD developers have not indicated whether
  264.   they plan on releasing a patch for NetBSD 1.0 users.  Note that the
  265.   sample NetBSD patch distributed with an earlier version of the memo
  266.   was incomplete; the version in the source tree as of October 18 is
  267.   correct.
  268.  
  269. * Sam Hartman <hartmans@mit.edu> patched the upcoming release of
  270.   Kerberos 5.  In addition, patches were generated against Kerberos 5
  271.   beta 5 and beta 4-3.  The can be found at
  272.   ftp://athena-dist.mit.edu/pub/kerberos/telnet-patch/.
  273.  
  274. * Mark Eichin <eichin@cygnus.com> prepared patches for CNS.  These
  275.   patches will be available on the Cygnus web site
  276.   http://www.cygnus.com/data/cns/telnetdpatch.html; support customers
  277.   are being contacted directly.
  278.  
  279. * OpenVision has a patch for the telnetd in OV*Secure 1.2 and will
  280.   contact its customers directly.
  281.  
  282. * Peter Tobias, <tobias@et-inf.fho-emden.de> released a patch for
  283.   Debian GNU/Linux.  This patch can be found in the networking
  284.   utilities at
  285.   ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.21-1.deb.
  286.  
  287. * Erik Troan <ewt@redhat.com> confirms that Redhat Linux is
  288.   vulnerable, indicating a patch can be found at
  289.   ftp://ftp.redhat.com/pub/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm
  290.   or
  291. ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm
  292.   The fix is incorporated into the Redhat 2.1 release.
  293.  
  294. * An SGI patch is available at ftp://sgigate.sgi.com/security/.
  295.  
  296. * DEC confirmed they will have a preliminary patch available on
  297. October 31; they will be contacting customers and releasing patch info
  298. to CERT.
  299.  
  300. * Andrey A. Chernov <ache@astral.msk.su> released a patch for FreeBSD,
  301.   but did not include an URL where the patch could be obtained.
  302.  
  303. * Bruce Lewis <brlewis@mit.edu> is preparing a patch for the
  304.   MIT-distributed Athena telnet/telnet95.  His patch is currently
  305.   available within MIT.  Within MIT, consult the netusers discuss
  306.   meeting for more details.
  307.  
  308.  
  309.                          Testing for Exposure
  310.  
  311.         In order to test to see if your telnetd passes environment
  312. variables that effect shared libraries, it is important to understand
  313. what environment variables are used by your runtime linker.  See the
  314. environment variables section for common examples.  To be sure, you
  315. should run strings over your runtime loader.  For example, the
  316. following shows the environment variables used by NetBSD:
  317.  
  318.   athena% strings - /usr/libexec/ld.so
  319.   ld.so
  320.   LD_LIBRARY_PATH
  321.   LD_PRELOAD
  322.   LD_NOSTD_PATH
  323.   LD_SUPPRESS_WARNINGS
  324.   LD_WARN_NON_PURE_CODE
  325.   LD_NO_INTERN_SEARCH
  326.   .init
  327.   Cannot set breakpoint (%s)
  328.   Cannot re-protect breakpoint (%s)
  329.   LD_TRACE_LOADED_OBJECTS
  330.  
  331.         Naturally, this is only an excerpt of the output.  Therefore,
  332. NetBSD probably honors the `LD_LIBRARY_PATH' variable.  It appears to
  333. honor several other variables as well.  (In fact, it honors most of
  334. the environment variables besides LD_PRELOAD, which hasn't been
  335. implemented yet.)  If a system were non-standard, it might not be easy
  336. to know what was an environment variable and what was just a string in
  337. the binary.  For example, the string `runpath' in the Solaris loader
  338. is not an environment variable, but a similar string `LIBPATH' in the
  339. AIX kernel is the AIX environment variable.  You also have to find the
  340. dynamic loader, which isn't always easy.  Look for a program called
  341. `rld', `ld.so', `loader', or some similar name.
  342.  
  343.         You should also check your vendor's documentation, but reading
  344. the documentation should not be a substitute for reading the binaries,
  345. for while binaries may deceive and obfuscate, they seldom lie.
  346.  
  347.         Now that you know what environment variables to check for,
  348. find out which telnetd your system runs.  Note that the telnetd on my
  349. system is almost certainly not in the same place as yours: this
  350. session took place on a machine in the Athena environment, so it is
  351. running a custom MIT telnetd.  However, the same techniques should
  352. work with `/etc/athena/telnetd' replaced with `/usr/sbin/in.telnetd'
  353. or whatever is appropriate for your system.
  354.  
  355.   athena% grep telnet /etc/inetd.conf
  356. telnet  stream  tcp     nowait  root    /etc/athena/telnetd     telnetd -a off
  357.   athena%
  358.  
  359.         Now, check to see if it looks like it handles environment
  360. options at all (by grepping for `ENVIRON') and if it does anything
  361. special with linker environment variables.  This test is *not*
  362. definitive: there are both false positives and negatives, but you can
  363. get a general idea of what to expect in later steps.
  364.  
  365.   athena% strings - /etc/athena/telnetd |grep ENVIRO
  366.   ENVIRON VALUE and VAR are reversed!
  367.   OLD-ENVIRON
  368.   NEW-ENVIRON
  369.   NEW-ENVIRON
  370.   athena% strings - /etc/athena/telnetd |grep LD_
  371.   athena%
  372.  
  373.         Ok, it looks very much like I have a problem.  My telnetd
  374. appears to support environment options--it even has an error message
  375. about it, but I see no mention of environment variables that should be
  376. restricted.  Note that even if I saw no environment info in telnetd, I
  377. would continue with the test just to make sure.
  378.  
  379.         For the next step, telnet to the machine and see if it passes
  380. environment options such as LD_LIBRARY_PATH.  Try to create a corrupt
  381. libc.so in /tmp by creating a zero length file of the same name; if
  382. the system is vulnerable, login will core dump when it tries to use
  383. the new libc.  If this test fails, try a test using `ps -e' to see if
  384. the environment variable got set.  In order to find out what library
  385. to create, I'll use the `ldd' command on the executable; you could
  386. also try looking through /lib, or under AIX, use `dump -H executable'.
  387.  
  388.   athena% ldd /etc/athena/telnetd
  389.   /etc/athena/telnetd:
  390.           -lcurses.2 => /usr/lib/libcurses.so.2.1 (0x10032000)
  391.           -ltermcap.0 => /usr/lib/libtermcap.so.0.0 (0x1003d000)
  392.           -lutil.3 => /usr/lib/libutil.so.3.1 (0x1003f000)
  393.           -lc.12 => /usr/lib/libc.so.12.3 (0x10041000)
  394.   athena% touch /tmp/libc.so.12.3
  395.  
  396.         Now, we try and connect:
  397.  
  398.   athena% telnet
  399.   ...including Athena's default telnet options: "-ax"
  400.   telnet> env define LD_LIBRARY_PATH /tmp:/var/tmp
  401.   telnet> env export LD_LIBRARY_PATH
  402.   telnet> set options
  403.   Will show option processing.
  404.   telnet> open vulnerable-machine
  405.   Trying 10.0.0.6...
  406.   Connected to telnet-bug-exploit.MIT.EDU.
  407.   Escape character is '^]'.
  408.   SENT WILL LFLOW
  409.   SENT WILL LINEMODE
  410.   SENT WILL NEW-ENVIRON
  411.   RCVD WILL SUPPRESS GO AHEAD
  412.   RCVD DONT LINEMODE
  413.   RCVD DO NEW-ENVIRON
  414.   SENT WONT XDISPLOC
  415.   RCVD DO OLD-ENVIRON
  416.   SENT WONT OLD-ENVIRON
  417.   SENT IAC SB TERMINAL-SPEED IS 9600,9600
  418.   RCVD IAC SB NEW-ENVIRON SEND
  419.   SENT IAC SB NEW-ENVIRON IS USERVAR "LD_LIBRARY_PATH" VALUE "/tmp:/var/tmp"
  420.  
  421.   MIT SIPB NetBSD-Athena (xxx) (ttyp1)
  422.  
  423.   ld.so: login: libc.so.12.3: Undefined error: 0
  424.   Connection closed by foreign host.
  425.   athena%
  426.  
  427.         This machine is obviously vulnerable.  Now, an example of what
  428. happens if for some strange reason, login actually works, but the
  429. machine is still potentially vulnerable: (telnet session as above, but
  430. a login prompt)
  431.  
  432.   telnet> open vulnerable-machine
  433.   Trying 10.0.0.6...
  434.   Connected to telnet-bug-exploit.MIT.EDU.
  435.   Escape character is '^]'.
  436.  
  437.   MIT SIPB NetBSD-Athena (xxx) (ttyp1)
  438.  
  439.   login:
  440.  
  441.         Now, we suspend the telnet and look at the login process that
  442. was created:
  443.  
  444.   athena% ps -ewwa |grep login
  445. 6997 p1  Is+    0:00.05 LD_LIBRARY_PATH=/tmp:/var/tmp TERM=vt100 login -h somew
  446.   athena%
  447.  
  448.         This indicates that the variable was passed, but login failed
  449. to act--possibly because you did something wrong when creating the
  450. library; your system is probably still vulnerable.  If that variable
  451. was not present, but the -e flag works on your ps, and other processes
  452. displayed environment variables, your system is likely not vulnerable.
  453. Also, if neither an old-environ nor new-environ option was passed
  454. between the telnetd and telnet, you are almost certainly safe.
  455. However, passing this test should not be taken as a guarantee of
  456. complete security: you should still contact your telnet vendor unless
  457. you are sure you are safe.
  458.  
  459.  
  460.                           Verifying a Patch
  461.  
  462.         In the process of talking to vendors, distributing patches,
  463. and getting feedback, I've come up with a lot of `almost solutions' --
  464. patches that are good enough to make you think they work, but that can
  465. be compromised.
  466.  
  467. * A clever trick to get around exact match patches is to embed an
  468.   equals sign in a variable name.  For example, ask your client to send
  469.   an option requesting that the variable
  470.   LD_LIBRARY_PATH=/home/hartmans/exploits/sun4lib: be set to the value
  471.   invalid:/lib:/usr/lib.  Naturally, the call to setenv in telnetd adds
  472.   another =, but that's soaked up by `invalid', and I still get to
  473.   break into the system.  I.E.  Deal with variable names containing
  474.   equals signs (=).
  475.  
  476. * At least in the Borman BSD telnet, there are two calls to setenv:
  477.   one for the last part of an environment option and one for the other
  478.   parts.  Make sure you cover both; this was the biggest problem with
  479.   the sample patch I first distributed.
  480.  
  481. * If it is possible to stuff a string into the environment twice with
  482.   your telnetd, make sure you check all entries in the environment.  For
  483.   example, if you have a setenv() that doesn't check for duplicates,
  484.   don't just use unsetenv() as this will remove the last item in the
  485.   environment, leaving the others to be used by login.
  486.  
  487. * Get all the important environment variables.  Follow the
  488.   instructions for testing vulnerability, and check all the potential
  489.   environment variables found when you strings the loader.
  490.   Considering the potential to miss variables, several people have
  491.   suggested only allowing certain variables through.  Borman is
  492.   investigating this and several other options; unfortunately,
  493.   anything less than a solution tailored to a particular vendor's
  494.   operating system decreases the functionality provided by the
  495.   environment option.
  496.  
  497.                              Sample Patch
  498.  
  499.         Below, I include the official patch to telnet from David
  500. Borman <dab@cray.com> as of October 23.  Before the patch, I include a
  501. message I received on October 19; this includes useful information.
  502. As I received the message, it was not PGP-signed; its inclusion in
  503. this signed summary indicates that it has not been modified since I
  504. received it, and says nothing about the integrity of the
  505. communications link between myself and Mr. Borman.  However, I have
  506. examined the patch, and it appears to be a valid fix for the bug.  It
  507. also corresponds to the appropriate sections of the diff on the ftp
  508. server.  Again, patches are provided as-is without a guarantee of
  509. correctness; you assume all risk for applying this patch. (As with all
  510. PGP-signed patches, you will need to remove leading dashes.)
  511.  
  512. Date: Thu, 19 Oct 95 13:54:56 CDT
  513. From: dab@berserkly.cray.com (David A. Borman)
  514. Message-Id: <9510191854.AA03474@frenzy.cray.com>
  515. To: hartmans@MIT.EDU
  516. Subject: Re: telnet vulnerability giving root access
  517. Cc: cert@cert.org, tytso@MIT.EDU
  518.  
  519.  
  520. I have placed a version of the BSD Telnet distribution at:
  521.  
  522.         ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z
  523.  
  524. with a fix for this problem.  It changes telnetd to remove the LD_*,
  525. _RLD_*, IFS and LIBPATH environment variables before execing login.
  526.  
  527. The version on ftp.cray.com does not contain the encryption code,
  528. that is on net-dist.mit.edu, and I have sent a new copy off to
  529. them to replace the current distribution.
  530.  
  531. (The attached diffs also show a bugfix for a problem that was
  532. screwing up /etc/utmp on Solaris.)
  533.  
  534. Also, BSDI is not affected, as they do not provide any way for
  535. the user to override the search path for shared libraries.
  536. UNICOS is unaffected, since we don't have shared libraries.
  537.  
  538. Please feel free to pass on this message.
  539.  
  540.                         -David Borman, dab@cray.com
  541. diff -cbr telnet.95.05.31/telnetd/sys_term.c telnet.95.10.23/telnetd/sys_term.c
  542. *** telnet.95.05.31/telnetd/sys_term.c  Wed May 31 00:50:57 1995
  543. - --- telnet.95.10.23/telnetd/sys_term.c        Mon Oct 23 09:47:17 1995
  544. ***************
  545. *** 32,38 ****
  546.    */
  547.  
  548.   #ifndef lint
  549. ! static char sccsid[] = "@(#)sys_term.c        8.4 (Berkeley) 5/30/95";
  550.   #endif /* not lint */
  551.  
  552.   #include "telnetd.h"
  553. - --- 32,38 ----
  554.    */
  555.  
  556.   #ifndef lint
  557. ! static char sccsid[] = "@(#)sys_term.c        8.4+1 (Berkeley) 5/30/95";
  558.   #endif /* not lint */
  559.  
  560.   #include "telnetd.h"
  561. ***************
  562. *** 1570,1579 ****
  563.         utmpx.ut_id[3] = SC_WILDC;
  564.         utmpx.ut_type = LOGIN_PROCESS;
  565.         (void) time(&utmpx.ut_tv.tv_sec);
  566. !       if (pututxline(&utmpx) == NULL)
  567. !               fatal(net, "pututxline failed");
  568.   #endif
  569.  
  570.         /*
  571.          * -h : pass on name of host.
  572.          *              WARNING:  -h is accepted by login if and only if
  573. - --- 1570,1581 ----
  574.         utmpx.ut_id[3] = SC_WILDC;
  575.         utmpx.ut_type = LOGIN_PROCESS;
  576.         (void) time(&utmpx.ut_tv.tv_sec);
  577. !       if (makeutx(&utmpx) == NULL)
  578. !               fatal(net, "makeutx failed");
  579.   #endif
  580.  
  581. +       scrub_env();
  582. +
  583.         /*
  584.          * -h : pass on name of host.
  585.          *              WARNING:  -h is accepted by login if and only if
  586. ***************
  587. *** 1809,1814 ****
  588. - --- 1811,1836 ----
  589.         return(argv);
  590.   }
  591.   #endif        /* NEWINIT */
  592. +
  593. + /*
  594. +  * scrub_env()
  595. +  *
  596. +  * Remove a few things from the environment that
  597. +  * don't need to be there.
  598. +  */
  599. + scrub_env()
  600. + {
  601. +       register char **cpp, **cpp2;
  602. +
  603. +       for (cpp2 = cpp = environ; *cpp; cpp++) {
  604. +               if (strncmp(*cpp, "LD_", 3) &&
  605. +                   strncmp(*cpp, "_RLD_", 5) &&
  606. +                   strncmp(*cpp, "LIBPATH=", 8) &&
  607. +                   strncmp(*cpp, "IFS=", 4))
  608. +                       *cpp2++ = *cpp;
  609. +       }
  610. +       *cpp2 = 0;
  611. + }
  612.  
  613.   /*
  614.    * cleanup()
  615.  
  616.  
  617.                            Acknowledgments
  618.  
  619.         In preparing this bug summary, I have received the help of
  620. several people.  In particular, I would like to thank David Borman for
  621. quickly fixing the problem once notified, and Bruce Lewis for
  622. supplying a timely solution to the problem within MIT.  In addition,
  623. John Hawkinson <jhawk@mit.edu> provided help developing exploit
  624. scripts and confirming that the bug existed on several systems.  In
  625. addition, I would like to thank vendor security contacts for being
  626. responsive and working quickly to get patches ready as soon as
  627. possible.  I would also like to thank those at MIT who reviewed drafts
  628. of this announcement and suggested improvements.
  629.  
  630.  
  631.